home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / September 96 / Re(2) Not Displaying Save Di.4 < prev    next >
Encoding:
Internet Message Format  |  1996-09-19  |  2.0 KB  |  [TEXT/ttxt]
  1. Subject:     Re(2): Not Displaying Save Dialog
  2. Sent:        9/18/96 3:55 PM
  3. Received:    9/18/96 3:55 PM
  4. From:        kswenson@keypress.com (Kirk Swenson)
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List
  7.  
  8.  
  9. >>I'm not on the ODF team, but I'll comment anyway.  ODFDraw changes the
  10. >>internal transform of the frame (which is persistent).  This causes OpenDoc
  11. >>to 'dirty' the document.
  12. >
  13. >Do you agree that users (not programmers) will have a hard time to figure
  14. >that out? I am a programmer and my first impression was that a bug in
  15. >ODFDraw had the part always marked dirty. My second impression was that a
  16. >bug in ODFDraw had the port sometimes marked dirty. I finally figured out
  17. >that ODF parts were marked dirty only when they had been scrolled. Then I
  18. >guessed changes to the internal transform was the problem, which you did
  19. >confirmed.
  20. >
  21. >I understand what's involded, but I think this is a problem as far as HI is
  22. >concerned. As OD parts begin to ship, I think there will be many users
  23. >reporting "Save Dialog" bugs. I think the solution is having auto-save
  24. >properties in OpenDoc, the internal transform of root parts being such a
  25. >property.
  26.  
  27. Personally, I think it's a problem, but there are other solutions besides
  28. auto-saving.  I'm not convinced that the internal transform should always
  29. be written out for all parts.  Is this an OpenDoc requirement?  Why not
  30. leave it up to each part to decide whether (and how) the internal transform
  31. should be persistent?  Some parts may always want to start in the upper
  32. left of their content, with a particular zoom factor, rather than returning
  33. to whatever was used last.  Parts may differ in whether they want to save
  34. if scroll position is the only thing that changed.  The problem here seems
  35. to be that something is being saved when we don't necessarily want or need
  36. it to be (the scroll position of the document).  Is saving more frequently
  37. at even more unexpected times really the solution?  Just a thought.
  38.  
  39. Kirk Swenson
  40. Senior Software Engineer
  41. Key Curriculum Press
  42. kswenson@keypress.com